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About This Guide 



Purpose 

This guide explains how to migrate from existing message control systems (MCSs) to the 
current release of the Communications Management System (COMS). COMS is an MCS 
designed for use with Unisys A Series systems. The COMS product is a member of the 
InterPro"* dnteractive Productivity) family of products. 

Scope 

The guide details the strategies, tools, and methods of evaluation available for nidation 
to COMS. 

This guide does not include information on migrating from one release to another. 
For information on compatibility issues across releases, refer to the Software Release 
Capabilities Ov«-view for the appropriate Mark release level For example, the A Series 
Mark 3.9 Software Release Capabilities Overview includes information about the Mark 
3.9 compatibility issues. 

Audience 

The guide is written for the system administrators and system progranmiers who are 
responsible for migration issues at their site. 

Prerequisites 

The users of the guide must be familiar with each existing MCS at their site and with 
COMS. 
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How to Use This Guide 

This guide is divided into five sections. Read section 1 when you are planning or 
reviewing your strategy for migrating to COMS. Section 2 is important if you intend to 
operate a user-created or Unisys MCS under COMS. 

Sections 3 and 4 detail different aspects of migrating from the Generalized Message 
Control System (GEMCOS) to COMS, and should be read if you are performing this 
migration. 

Section 5 gives you information on how remote files are handled if you migrate to COMS, 
and compares this handling with that of the Command and Edit language (CANDE) 
system. 

For convenience, the symbols that appear in this guide are used in the same manner as 
they are used in related documents. For example, square brackets ( [ ] ) are used as part 
of GEMCOS declarations, and angle brackets ( <> ) denote metatokens and variable 
information. 

Since the guide is addressed to users who are familiar with existing MCSs at their site 
and with COMS, many of the terms, acronyms, and concepts in the guide that are 
integral to COMS, GEMCOS, or other Unis3rs MCSs are not included in the glossary or 
index. 

Unless otherwise stated, all documents referenced in the guide are A Series doctunents. 

Organization 

The individual sections are described in the following outline of the document. In 
addition, a glossary, a bibliography, and an index appear at the end of this guide. 

Section 1. Migrating to COMS 

This section outlines the major benefits of u^ng COMS, the migration strategies, and the 
factors to consider when selecting a migration path for your site. 

Section 2. MCS Windows 

This section describes the MCS window feature of COMS and provides information 
to help system programmers decide if any changes are needed to make a given MCS 
operate in a COMS environment. 

Sections. Format Support Library 

One tool used in the direct migration from GEMCOS to COMS, the format support 
library processing item, is examined. The section covers the preparation, installation, 
and use of the format support library to retain your GEMCOS input formatting, output 
formatting, form requests, and pa^i^. 
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Section 4. GEMCOS Windows 

Guidelines are presented for running GEMCOS in an MCS window, and various aspects 
of GEMCOS operation through COMS are considered. 

Section 5. Remote Files 

This section compares the handling of remote files throu^ COMS with the handling of 
remote files through CANDE. Emphasis is placed on how COMS handles remote files. 

Appendix A. Comparing GEMCOS to COMS 

This appendix compares GEMCOS and COMS functions and features. 

Appendix B. GEMCOS Sources for COMS Entities and Attributes 
This appendix gives the GEMCOS sources for COMS entities and attributes. 

Related Product Information 

For more information about COMS, refer to the following documents: 

A Series Communicationa Management Syaiem (COMBS) Capabilities Manual 
(form 8600 0627) 

This manual introduces COMS, discusses the flexibility and efficiency of the COMS 
i^3^em, describes the COMS architecture, and discusses spedfic features available to the 
COMS user. This manual is written for upper management, the site manager, and the 
programming staff. 

A Series Communications M€magement System (COMS) Configuration Guide 
(form 8600 0312) 

This guide provides an overview of the basic concepts and functions of COMS. It includes 
instructions for creating a workii^ COMS configuration and information on how to 
monitor and fine-tune COMS system performance. This guide is written for installation 
analysts, system analysts, programmers, administrators, and performance analysts. 

A Series Communications Management System (COMS) Operations Guide 
(form 8600 0833) 

This guide eaplains how to perform terminal-based (X)MS functional tasks and serves as 
a reference to COMS commands. Syntax diagrams of COMS commands are provided 
with explanations and examples of how the commands can be used. This guide is written 
for terminal operators and computer operators. 

A Series Communications Management System (COMS) Programming Guide 
(form 8600 0650) 

This guide explains how to write online, interactive, and batch application programs that 
run under COMS. This guide is written for experienced applications programmers with 
knowledge of data conmoiunication subsystems. 
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Section 1 

Migrating to COMS 



This section outlines the benefits of the full-featured Communications Management 
System (COMS), the available routes and tools for migration to COMS, and the factors 
that influ^ce migration. 

Why COMS? 

COMS is a part of the Unisys InterPro (Interactive Productivity) family of products. It 
serves as the message control system (MCS) and supports processing on the Unis3rs 
A Series systems. 

COMS allows you to select only the features you need for your processing. You can 
choose features such as a menu-driven user interface provided by the Menu- Assisted 
Resource Clontrol (MARC), transaction processix^, and real-tune configuration changes. 

COMS windows enable you to operate a nimiber of program environments 
simultaneously at a given station. Without loggii^ off, you can switch from window to 
window and retain the states of your window dialogs. 

The close integration of COMS with the operating sfystem guarantees h%h performance, 
especially for the direct window interface. 

The available COMS processing items and windows are important factors in your 
migration plan. 

COMS Versions 

Two versions of COMS are available to you, and both use the COMS configuration file to 
provide the mess£^ control environment. The fuU-featured version of COMS enables 
you to make changes to the configuration file. The COMS (Kernel) version comes with a 
predefined configuration file that cannot be manipulated. 

Full-Featured COMS 

The full-featured version of COMS offers the following: 

• Eight dialogs each on the Menu- Assisted Resource Control (MARC) window, the 
Command and Edit (CANDE) window, and the Generalized Message Control System 
(GEMCOS) window for each connection. 

• Preprocessing and postprocessing of messages. 

• Routing by transaction code (trancode). 
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• User-defined usercodes and station restrictions. 

• Djoiamic control of user-created interface programs. 

• Security options, such as security by trancode. 

• Batch processing. 

• Synchronized recovery. 

• GEMCOS-to-COMS migration aids. 

COMS (Kernel) 

COMS (Kernel) is a version of COMS that has minimum features compared to the 
full-featured version of COMS. COMS (Kernel) comes with a predefined configuration 
file, but does not include the reconfiguration capabilities found in the COMS Utility 
program. The COMS (Kernel) configuration file enables you to use the window feature, 
but does not include the COMS Utility window. Although COMS (Kernel) is mentioned 
here, some of the features discussed in this guide might be found only in the full-featured 
version of COMS. 



COMS Windows and Dialogs 

COMS windows and dialogs are basic to most migration strategies. Four windows are 
defined by COMS at system initialization: 

• MABC window 

• COMS Utility window 

• CANDE window 

• 6EMC0S window 



The MARC window handles network control, data comm errors, and COMS termination. 
This window is a menu-driven interface to sfystem resources that can be selected for an 
installation. The MARC window is similar to CANDE in the way it runs and controls 
application programs. 

The COliiS Utility window is accessible on^ from a control station, from the operator 
display terminal (ODD* or through a control-capable usercode. Through the COMS 
Utility window, you can define and maintain the COMS control file. 

The CANDE and GEMCOS windows provide access to CANDE and GEMCOS, 
respectively. 

There are three types of COMS windows: 

• Direct windows 

• MCS windows 

• Remote-file windows 
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Direct windows are used to perform transaction-oriented processing that provides 
database synchronized recovery. MCS windows access message control systems other 
than COMS. Remote-file windows access remote-file programs. 

The MARC and COMS Utility windows are direct windows. The CANDE and GEMCOS 
windows are MCS windows. Both direct and MCS windows can be declared through 
the COMS Utility. Remote-file windows can be declared throu^ the COMS Utility, or 
dynamically created by executing a program that opens a remote file. 

Access to a program environment through a window is caUed a dialog. COMS allows 
multiple and simultaneous dialogs with the same window during the same session. Each 
dial(^ is treated as an independent session with a program environment. 

Migrating Directly or Using a COIVIS IVICS Window 

When you migrate directly to COMS, you replace your current message control system 
(MCS) with COMS. If you decide to delay replacement of your MCS with COMS, you can 
establish a COMS MCS window in which to operate your MCS. 

Your current MCS, the size and complexity of your current applications, available 
expertise, hardware, and the features and functions offered by COMS all influence your 
choice of a migration strategy. 

IVIigrating Directly to COMS 

The direct approach consists of performing all required tasks to replace your current 
MCS or MCSs with COMS at one time. Depending on your MCS or MCSs, direct 
migration can mean simultaneously modifying your database, changing your application 
programs, and creating COMS entities. 

For information on modifying your database and creatii^ COMS entities, refer to the 
COMS Configuration Guide. The COMS Programming Guide contains information on 
how to write application programs for transaction processing that run under COMS. 

Direct migration might involve replacing a user-created MCS or MCSs with COMS. 
For example, user-created dial-out MCSs can be replaced with COMS-suppIied dial-out 
facilities. Remote printing MCSs can be replaced with Unisys Remote Print S3rstems 
(Reprints). (Under Reprints, the remote destination must be a data comm station 
controlled fay MARC and COMS.) 

Direct migration from GEMCOS to COMS involves the specific steps and considerations 
outlined in the paragraphs that follow. The format support Hbraxy (FS-LIB) described in 
Section 3 can assist in your direct migration strategy. 

Migrating Directly from GEMCOS to COMS 

If you currently use GEMCOS, you can migrate directly to COMS if you alter 3rour 
Implication programs and COMS to emulate or accommodate the features of GEMCOS. 
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The following five steps outline the basic strategy of a direct migration from GEMCOS to 
COMS. 



1. 



Install GEMCOS on a Mark Release, level 3.5 or later. 



2. 



Install COMS and MARC. 



3. 



Change the database restart data set to support COMS recovery. 



4. Convert your GEMCOS application programs into programs that use COMS 



5. Translate the network description in the GEMCOS transaction control language 
(TCL) control file into a network description that can be understood and used by 



COBOL(68) programs do not need to be converted to COBOL74. However, COBOL74 
has language support for the COMS interface. Witia. C060L(68) you must program the 
interface usii^ LIBRARY calls. 



For the direct m^ation to be successM, the network description specified in the TCL 
control file needs to be translated into a network description that can be understood and 
used by COMS. GEMCOS entities (categories of information in the control file) need to 
be translated into COMS entities. 

Most GEMCOS entities have a direct COMS counterpart. For example, the GEMCOS 
entity called a SYSTEM is the counterpart of the COMS WINDOW entity. 

The following table lists several GEMCOS entities and their COMS counterparts. 

GEMCOS COMS 

SYSTEM WINDOW 

PROGRAM PROGRAM 

INPUTQUEUE AGENDA 

STATION STATION 

DEVICE DEVICE.TYPE 

The "GEMCOS Sources for COMS Entities and Attributes" i^ipendix ghres the 
GEMCOS counterpart for each COMS entity. 



GEMCOS Features in a COMS Environment 

Before beginning a direct migration, read the '^Comparing GEMCOS to COMS** 
appendix to see if the GEMCOS features you need are supported under COMS. 

If you need another feature, consider creating your own processing item to support the 
feature. 



programming conventions. 



COMS. 



Translating a GEMCOS TCL Control File 



1-4 



8600 1567-000 



Migrating to COMS 



GEMCOS Formatting under COMS 

The format support library available with COMS provides GEMCOS formatting and 
pagix^ features in the COMS environment. The Screen Design Fadlity (SDF), another 
InterPro product, also can be used to provide formatting for devices compatible with 
ET 1100 terminals. 

Operating under an MCS Window 

Under COMS, a window provides access to a program or system. MCS windows give you 
access to message control systems (MCSs). A site can have a maximum of 1023 windows. 
Only four windows (MARC, COMS Utility, CANDE, and GEMCOS) are defined at 
system initialization. You can define additional windows any time. You could define a 
window for each message control system supported at your site. Refer to Section 2 for 
more information on MCS windows. 

Accessing an MCS 

When you access an MCS through a COMS window, the MCS and its application 
programs do not have to be modified. (This is a major difference firom direct migration, 
in which the programs must be modified.) For example, CANDE and programs running 
under CANDE need no modifications to operate under a COMS window. However, as 
shown below, vi^jog an MCS window creates an extra processing layer. 

Performance under a COMS Window 

There are no performance benefits when you run any MCS under a COMS window. 

Using the GEMCOS Window 

The Kernel version of COMS enables a station to have one d&sHog with the GEMCOS 
window. The Kernel version does not offer the conveniences and benefits of the 
full-featured version of COMS. The full-featured version allows multiple and 
simultaneous dialogs with GEMCOS at one station and gives current GEMCOS users 
the windows and menu-driven features provided by CX)MS. However, the GEMCOS 
window should be used only as a short-term strategy in the m^^ration to COMS. 

Figure 1-1 shows what happens when you run GEMCOS under an MCS window. The 
extra k^rer, COMS itself, is used when any MCS operates under a window. This extra 
layer can hinder performance. 
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GEMCOS Alone: 

Application Program < — > GEMCOS < — > Hardware 
GEMCOS under COMS: 

Application Program < — > GEMCOS < — > COMS < — > Hardware 

Figure 1-1. Adding a Software Layer by Running GEMCOS under a COMS Window 



In most situations, you should use the GEMCOS window as an interim tool before you 
begin converting your GEMCOS application programs. However, CP 2000 users must 
use the GEMCOS window; GEMCOS cannot directly access CP 2000 stations. For more 
details about GEMCOS windows, read Section 2. 



Migration Assistance 

If you have a m^rration solution that is not covered in this docum^t or if you have 
created a migration tool that you would like to share with others, please send a detailed 
description to your local Unisys technical representative. 

If you have a problem that requires immediate attention, contact your local Unisys 
technical representative. 
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This section describes the characteristics of a Communications Management System 
(COMS) message control system (MCS) window and indicates how it works. The 
section describes how COMS handles various DCWBTTEs with respect to an MCS 
window, and presents DCWRTTE-message and result-message formats. DCWEITEs are 
intrinsic functions that cause messages usii^ these functions to be passed to the data 
conmiimications conlToUer (DCC) for action. 

The information in this section pertains to a COMS MCS window in general, that is, 
a COMS MCS window that is used for any given message control system (MCS). For 
information about nmning the Generalized Messs^ Control System (GEMCOS) in a 
COMS MCS window, refer to Section 4. 

The following topics are presented in this section: 

• General description of a COMS MCS window 

• MCS-controUed pseudostations 

• Naming conventions for pseudostations 

• Requirements for an MCS to fundion through COMS 

• Entering control commands 

• Handling of DCWBTTEs 

• DCWBTTE-mess£^ and result-message formats 

For additional information about pseudostations and DCWBTTEs, refer to the 
DCALGOL Reference Manual. 

Unless indicated otherwise, the information in this section s^plies to a station or 
pseudostation controlled by an MCS operating either with the CP 2000 front-end 
processor throu^ COMS or with the network support processor (NSP) through COMS. 

Note that a given MCS operating with the NSP through COMS may have more 
capabilities than the same MCS operating with the CP 2000 through COMS. 

Note also that an installation that includes both the CP 2000 and the NSP can have a 
mixed network in which stations and pseudostations controlled by an MCS can operate 
individually. These stations and pseudostations can fimction in any or all the following 
ways: 

• With the CP 2000 through COMS 

• With the NSP through COMS 

• Directly under the NSP 
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Note: The LSCANDE virtual-terminal protocol must be used for a terminal 
to operate with the CP 2000 through COMS. 

General Description of a COMS IVICS Window 

A COMS MCS window is a feature that enables you to have a number of independent 
sessions (dialogs) with an MCS simultaneous^ at a dng^e station, if that MCS is installed 
on the network. Examples of MCSs are the Command and Edit (CANDE) ^tem, 
6EMC0S, and user-provided MCSs. 

The Kernel version of COMS enables a station to have up to two dialogs of the CANDE 
window and one dialog of the GEMCOS window at the same time. 

Tlie full-featured version of COMS provides a means to define MCS windows through 
the COMS Utility program, as described in the COMS Configuration Guide. The COMS 
Utility can be used to define a number of MCS windows for one or more kuids of MCSs. 

Once an MCS window is defined through the COMS Utility program for an installed 
MCS, you can have a number of simultaneous dialogs with the MCS at your station. 
The window can be defined through the COMS Utility to allow a maximum of eight 
simtdtaneous dialogs with the MCS at aziy station. You can then perform various 
activities associated with that MCS at the sanie tinie on one pl^sdcal terminal 

In general, the windowing capabilities of COMS enable you to perform a variety of 
activities simultaneously on tije terminal These activities can be associated with one or 
any number of MCSs and other systems that have been installed and window-defined. 

For information about controlling window dialogs at a terminal, refer to the COMS 
Operations Guide. 

MCS-Controlied Pseudostations 

When you open a dialog of a COMS MCS window at your station, the dialog is 
established throu^ an operatii^ssrston feature caUedapseudbsta^n. A pseudostation 
is a virtual station that can be attached to and controlled fay an MCS in much the same 
way as a real station. Unlike a real station, however, a pseudostation is not declared 
in the Network Definition Language n CNDUD, has no Une assigned, and needs no 
corresponding plQTsicai terminal on the local host. 

For every MCS window dialog that you open, COMS allocates a pseudostation and 
transfers it to the MCS in question. Each DCWBTTE that the MCS performs on the 
pseudostation is handled in (me of the fdlowii^ ways: 

• Handled entirely by the operating systeuL The DCWBTTE works as it would for a 
real station. 

• Handled primarily by the operating system, with some interpretation by COMS. 

• Interpreted by COMS. 

• Rejected because it is not allowed on a pseudostation. 
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The pseudostation featvire enables COMS to implement MCS windows. This feattire 
does not apply to COMS direct windows or remote-file windows. When information is 
input throng the MCS window dialogs at a given real station, the resulting output to 
the user is handled as if the response were to a number of real stations. In fact, only one 
terminal is involved. 

In a COMS environment, the MCS or MCSs handling the input/output never come in 
contact with the name corresponding to the real station. Rather, the MCS or MCSs 
recognize the name of the pseudostation corresponding to each dialog. 

You can recognize output associated with a particular MCS window dialog means of 
the pseudostation name identifying that output. 

Naming Conventions for Pseudostations 

Pseudostation names are assigned automatically by COMS. When your station is on the 
local host, the naming convention for pseudostations is as follows: 

<NOLII station naine>/<MCS window naine>/<dia1og number> 

Example 

ABC/CANDE/2 

When your station has been transferred to another host through BNA, the naming 
convention for pseudostations is as follows: 

<system host ID>/<NDLII station naine>/<MCS window naine>/<di al og number> 

Example 

A9A/ABC/CANDE/2 

Requirements for an IVICS to Function througli COIVIS 

In general, an MCS that presently works with real stations on lines needs no 
modification to function in a COMS MCS window if the MCS satisfies all the following 
requirements: 

• The MCS does not identify its stations using the DLS number format, shown below: 

<relative NSP number>:<1ine number>:<station number> 
Instead, the MCS identifies its stations using the logical station number (LSN). 

• The MCS does not have to reconfigure the network and handle switched lines as 
part of the application. 

• The MCS does not communicate with the data comm subsystem through tog^es and 
tallies. 
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Entering Control Commands 

The following information is provided to help a station user communicating through a 
COMS MCS window to enter control conmiands directed to COMS or the given MCS. 

If you enter a control command prefixed by one question mark (?), COMS always 
responds to the command, even if the command ^tax is identical to that of a control 
command associated with the given MCS. If your entered control command prefixed by 
one question mark is not a COMS conmiand, it is sent to the MCS. 

If you enter a control command associated with the given MCS prefixed by two question 
marks (??), the command is always sent to the MCS, even if the command syntax is 
identical to that of a COMS control command. 

Handling of DCWRITEs 

DCWKITEs are DCALGOL intrinsic functions that cause specified messages constructed 
to use these fimctions to be passed to the data communications controller (DCC) for 
action. The action that the DCC takes on a message depends on the type and variant 
fields of the message. 

Information about the handling of DCWBTTEs for a pseudostation in a COMS MCS 
window is presented in the paragraphs that follow. The information is presented in 
tables under the following categories: 

• DCWRPTEs handled by the operating S3rstem 

• DCWRTTBs interpreted by COMS 

• Result messages given by COMS 

• DCWRITEs not allowed by COMS 
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DCWRITEs Handled by the Operating System 

Table 2-1 lists the type numbers and corresponding functions for DCWRITEs that either 
are handled entirely by the operatii^ system or primarily by the operating system for a 
pseudostation in a COMS MCS window. 

COMS is notified of the DCWKETEs that are handled primarily by the operating system, 
and COMS takes some action on these DCWETTEs. In Table 2-1, these DCWRITEs 
are identified by the parenthetical note "(some COMS action taken)." The action that 
COMS takes on each of these DCWRITEs is indicated in Table 2-2. 



Table 2-1. DCWRITEs Handled by the Operating System 



UuWRITc 

Type Number 


DCWRITE Function 


00 


Initialize primary queue. 


01 


Attach station (some COMS action tal<en). 


02 


Interrogate MCS. 


03 


Communicate among MCSs. 


04 


Interrogate station environment. 


05 


Attach schedule station. 


32 


Change current queue (some COMS action taken). 


42 


Detach station. 


45 


Transfer station control. 


64 


Assign station to file (some COMS action taken). 


65 


Write to object job. 


66 


Cause station break. 


67 


Add station to file (some COMS action taken). 


69 


Subtract station from file. 


129 


Exchange clusters. 


131 


Update line attributes. 
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DCWRITEs Interpreted by COMS 

Table 2-2 lists the type numbers and corresponding functions for DCWBITEs that are 
interpreted by COMS for a pseudostation in a COMS MCS window. The action that 
COMS takes on each of these DCWBITES is indicated in the table. 

Note that the expression ''giving dununy good result to MCS" in the table means that 
COMS is notii^nng the MCS that the fimction associated with the particular DCWI^ 
has been accomplished. The expression does not mean that COMS performs the 
function. 



Table 2-2. DCWRITEs Interpreted by COMS 



DCWRITE 
Type 
Number 


DCWRITE Function 


COMS Action 


01 


Attach station. 


Determine whether a good result is 
required by the MCS. 


32 


Change cunent queue. 


Determine whether a good result is 
required by the MCS. 


33 


Write. 


Send text; return the result to the MCS 
if wanted. 


34 


Read-once only. 


No action. 


35 


Enable input. 


Indicate that the input has been 
enabled by giving a dummy good 
result to the MCS. 


36 


Disable input. 


Indicate that the input has been 
disabled by giving a dummy good 
result to the MCS. 


37 


Make station ready/not ready: 


Resume or suspend window dialog. 
Make pseudostation ready or not 
ready. Give results to the MCS. 


38 


Set application numt)er. 


Indicate that the application number 
has been set by giving a dummy good 
result to the MCS. 


39 


Set characters. 


Indicate that the characters have been 
set by giving a dummy good result to 
the MCS. 


40 


Set transmission number. 


Indk:ate that the transmission number 
has been set by giving a dummy good 
result to the MCS. 



continued 
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Table 2-2. DCWRITEs Interpreted by COMS (cont.) 



DCWRITE 
Type 
Number 


DCWRITE Function 


COMS Action 


41 


Recall message for the following 
four situations: 






COMS is recalling. 


Give a result to the MCS indicating 
that no message has been recalled. 




MCS wants only first 
message. 


Give a result to the MCS indicating 
that no message has been recalled. 




Object job output 


Recall the first message. Give it to the 
MCS. 




Else 


Recall all messages. Give them to the 
MCS. 


43 


SeVreset LOGICALACK (logical 
acknowledgement). 


Indicate that LOGICALACK has been 
set or reset by giving a dummy good 
result to the MCS. 


44 


Acknowledge. 


Indicate that acknowledgement has 
been made by giving a dummy good 
result to the MCS. 


46 


Write and retum. 


Send text; return the result if wanted. 


48 


Request null station. 


Issue a null request (for NSP) or issue 
minor synchronization (for CP 2000). 


64 


Assign station to file. 


Send text out if it applies to the 
message. 


67 


Add station to file. 


Send text out if it applies to the 
message. 


68 


Change terminal attributes. 


No action. 


96 


Make line ready. 


Indicate that the line has been made 
ready by giving a dummy good result 
to the MCS. 


97 


Make line not ready. 


Indicate that the line has been made 
not ready by giving a dummy good 
result to the MCS. 


103 


Sel/reset line tc^les/tallies. 


No action. 


105 


Force line not ready. 


No action. 
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Result Messages Given by COMS 

Table 2-3 lists the values for and descriptions of DCJWEITE resiilt messages that COMS 
gives to the MCS for a pseudostation in a COMS MCS window. An explanation of how 
COMS handles the result for each of these result messages is indicated in the table. 



Table 2-3. DCWRITE Result Messages Given by COMS 



Result 
Message 
Value 


Message Description 


Explanation 


00 


Good input 


Message with text is input. 


01 


Station event 


Only the control message variant of the 
input event type is given to the MCS. 


02 


File open 


Not affected by COMS. 


03 


Object job output 


Not affected by COMS. 




riic uiUdC 




05 


Good results 


Good results are generated for all 
OCWRITEs that give 05 for a real station. 


06 


Recalled message 


The message is recalled. 


14 


Station detached 


The window is closed (that is, the 
pseudostation with the specified Logical 
Station Number (LSN) is deallocated). 


15 


Interrogate station 


Pieces of information relating environment 
result to the pseudostation are retumed. 


16 


Hansfer station result 


Not affected by COMS. 


18 


ODT-to-station result 


Not affected by COMS. 


99 


Error result 


An error result is generated only for the 
break case-that Is, only for a break from a 
terminal devtee or printer. 
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DCWRITEs Not Allowed by COMS 

Table 2-4 lists the type niunbers and corresponding functions for DCWRITEs that are 
not allowed for a pseudostation in a COMS MCS window. 



Table 2-4. DCWRITEs Not Allowed by COMS 



DCWRITE Type 
Number 


DCWRITE Function 


49 


Set or reset sequence mode. 


53 


Write to transferred station. 


55 


Send result message to tiie MCS. 


56 


Set pseudostation attributes. 


98 


Dial out. 


99 


Disconnect. 


100 


Answer the phone. 


101 


Interrogate switched status. 


102 


Set or reset autoanswer. 


128 


Swap lines. 


130 


Move, add, or subtract station. 


If an attempt is made to execute a DCWRTTE that is not allowed on a pseudostation in 
a COMS MCS window, one of the error messages listed in Table 2-5 is returned on the 
call. 




Table 2-5. Error Messages 


Error Message Value 


Description 


188 


That DCWRITE Is not allowed on a pseudostation. 


190 


The pseudostation already has a fully participating MCS. Therefore, 
the requested type of transfer-station DCWRITE cannot be granted. 


192 


That DCWRITE is allowed only by a fully participating MCS. 



For a discussion of "full participation," refer to the DCALGOL Reference Manual. 
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Formats of DCWRITE Messages and Result Messages 

The fonnats of DCWBTTE messages and result messages associated with particular 
DCWETTEs are presented in the paragraphs that follow. These formats are presented to 
show the way COMS handles fields in the header and in other words of these messages, 
such as the text. 



DCWRITE Message Format 

The format of DCWRITE messages used in connection with DCWRITE 33 (WRITE) and 
DCWBTTE 46 (WRITE and RETURN) is presented in Table 2-6. Fields in this message 
format are identified and described in the table. The table indicates which fields are 
handled by COMS, and specifies how some of these fields are handled. The table also 
indicates fields that are not handled by COMS. Brief explanations of the fields handled 
l>y COMS follow the table. 

Additional information about the fields described in Table 2-6 is presented in the 
DCALGOL Reference Manual. 



Table 2-6. DCWRITE Message Format 



WorcVFieM 


ReM Description 


How Field is Affected by 
COMS 


MSGC0].[47:08] 


Type 


Handled 


MSG[d].[39:161 


Carriage control 


Fonvarded to the network 


MSGC0].C23:24] 


LSN 


Mapped onto real station 


MSG[1].[47:01] 


(Not used) 




MSGC1U46:07] 


Priority 


Not handled 


MSGC1].C39:081 


Tories 


Not handled 


MSGC1].[31:32] 


(Not used) 




MSG[2].[47:08] 


Retry count 


Not handled 


MSG[2].C39:16] 


Text size 


Handled 


MSG[2].[23:24] 


(Not used) 




MSGI3].[47:24] 


(Not used) 




MSG[3].[23:241 


Tallies 


Not handled 


MSG[4].[47:24] 


Message number 


Saved for result message 


MSG[4].[23:24] 


(Not used) 




MSG[5] 


(Not used) 




MSG[6]-MSG[N] 


Text 


Handled 
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The type field (MSG[0].[47:08]) contains a value that tells the DCWBITE fxmction which 
operation to perform. 

The carriage control field (MSG[0] . [39: 16]) provides information about advancement of 
position in the output device. 

The LSN field (MS6[0].[23:24]) designates the pseudostation to be affected by the 
DCWBITE function. 

The text size field (MSG[2].[39:16]) specifies the number of bytes of text in the message 
minus the number of bytes in the message header. 

The message number field (MSG[4]. [47:24]) contains a value that identifies the message 
to the MCS. 

The text field (MSG[6]-MSG[N]) contains the text of the message. This field is left 
justified and starts in word 6 of the message. 

Result Message Formats 

Table 2-7 presents the format of result messages returned for DCWRTTE 33 (WRITE) 
and DCWMTB 46 (WKITE and RETURN). 

Table 2-8 presents the format of result messages returned for DCWRTTE 41 (RECALL 
message). 

In these tables, fields in each of the result message formats are identified and described, 
and the returned information is shown. Brief explanations of fields for which 
information is returned follow the tables. 

Additional information about the fields described in Tables 2-^7 and 2-^8 is presented in 
the DCALGOLRefsrence Manual. 
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Table 2-7. Format of Result Messages Returned for DCWRITEs 33 (WRITE) and 46 
(WRITE and RETURN) 



Wor«VFIeld 


ndd Description 


Returned Information 


MSGC0].[47:08] 


Class 


05 


MSG[0].[39:16] 


Variant 


00 


MSGC0].[23:24] 


LSN 


Pseudo-LSN 


MSG[1] 




00 


MSGC2] 




00 


MSG[3] 




00 


MSG[4].[47:24] 


Message number 


Value In original DCWRITE 


MSG[4].[23:24] 


Original DCWRITE 


Original DCWRITE (33 or 
46) 


MSG[5] 




00 


MSQ[6]-MSG[N] 


Text 


Not returned 


Tible 2-8. Format of Result Messages Returned for DCWRITE 41 (RECALL Message) 


Wdrd/FMd 


Field Deseriiitlon 


Returned Information 


MSG[0].[47:08] 


Class 


06 


MSG[0].[39:16] 


Variant 


OOorOl 


MSG[0].[23:24] 


LSN 


Pseudo-LSN 


MSG[1] 




00 


MSGC2] 




00 


MSG[3] 




00 


MSG[4].[47:24] 


Message number 


Value In original DCWRITE 


MSG[4].[23:24] 




00 


MSQ[5] 




00 


MSGC6]-MSG[N] 


Text 


Not returned 



The dass field (MSG[0].[47:08]) contains a value that determines the way in which the 
remainder of the message is interpreted. 

The variant field (MSG[0].[39:16]) indicateis qualification, variations, or additional 
information concerning the message type. 
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The LSN field (MSG[0].[23:24]) designates the pseudostation destination for the result 
message. 

The message number field (MSG[4]. [47:24]) contains a value that identifies the original 
DCWRTTE to the MCS. 
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With Communications Management System (COMS) direct windows, you can process 
messages before they are received programs on input (preprocessing) or before they 
are sent to a device on output (postprocessing). Processing is performed by processing 
items. The processu:^ items must be defined in the COMS configuration file through the 
COMSUtiUty. 

Processing items are grouped into processii^-item lists. Processing-item lists are placed 
in agendas to determine which items to apply to messe^es that invoke the agendas on 
input or output. The agendas are also defined to route the messages to destination 
programs for the agenda. 

The ability to direct preprocessing and postprocessing of messages makes a processing 
item an excellent tool to maintain Generalized Message Control System (GEMCOS) 
formattix^ and paging in the COMS environment. COMS provides a format support 
library (FS-LIB) with an ACTUALNAME of TCL_FORMATTER to maintain GEMCOS 
input formatting output formattii^ forms request, pagii^, and library formats. 

The FS-LIB should be included in aii7 COMS agenda that needs to perform GEMCOS 
mess£^e formatting. This processii^ item can be used in a direct migration approach 
and with the Screen Design Facility (SDF). 

Note: You cannot use the FS-UB when running progrcuns under any MCS window. 
This section covers the following topics: 

• When and how to use the processix^ item 

• Using the format support library with SDF 

• GEMCOS formatting retained under COMS through the processing item 

• Performance when using the processing item 

• The logical flow of the processix^ item 

• The needed COMS environment 

• How to prepare the GEMCOS transaction control language (TCL) file to work in the 
COMS environment 

Why You Should Use the Format Support Library 

The format support library (FS-LIB) is designed to be used in the direct migration 
from GEMCOS to COMS. It emulates GEMCOS formatting features in the COMS 
environment. The library enables you to maintain the formatting specified in the 
GEMCOS TCL file while running under COMS. If another feature or fimction is needed, 
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you can create your own processing item and include it in the appropriate agenda or 
agendas. 

As described below, the FS-LTR can be used with the Screen Design Facility (SDF). You 
can use SDF instead of the processing item, or you can use SDF with the processing 
item. 

Using the Format Support Library with SDF 

SDF is an InterPro product designed to create and maintain forms. SDF generates 
processing items that are used by COMS for formatting. 

The format support library (FS-UB) and the SDF processing items can be used at the 
same time. The SDF processing items should be placed after the FS-LIB in the agenda's . 
processing-item list for both input and output messages. 

If the FS-LIB does any formatting, it sets the first word of the program's conversation 
area to all Is. SDF processing items examine the first word of the program's 
Conversation area on both input and output. If the word has all bits set to 1, SDF knows 
the FS-UB has done the formatting; SDF does not process the data. If the word does 
not have all bits set to 1, processing continues and SDF formatting is performed. 

GEMCOS Formatting Retained in COIVIS 

Formatting defines how a message is handled prior to its delivery to a program (input 
messages) or an output device (output messages). The format support lihraxy (FS-LIB) 
emulates 6£MCX)S formatting by performing the following fimctions: 

• Formatting input and output messages 

• Handling forms request 

• Handling pagix^ 

• Siq>porting user-created format libraries 



Formatting Input and Output Messages 

Stations are grouped by device dass. By identifying the device class and either the 
message key or message ID, the FS-LIB applies the proper format to a message. 

Making a Forms Request 

A forms request is a request for a blank form When the request is processed, the 
terminal displays only prompts and format-supplied defaults; no previously entered 
values are shown. To make a forms request, a station transmits an output message ID 
with no data and no special terminating character. 
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Dividing IVIessages into Pages 

Paging is dividing a message into distinct segments. This is usually done when 

• The message is too long or crowded for the entire message to be displayed on the 
terminal at one time. 

• The programmer wants to make specific distinctions between parts of the message. 

A messs^e can be divided into two or more pages. A given message can be paged at one 
device type and not paged at another device type. Both input and output messages can 
bepe^ed. 

Because the FS-LEB operates as a processii^ item, paging is applied separately on each 
SEND executed by a program. Therefore, paging cannot be applied across all segments 
of a segmented messs^e. 

When a station enters paging mode, COMS examines the first character of transmitted 
data to determine what action to take. The same characters that control the GEMCOS 
paging dialog also control the COMS FS-T«TR paging dialog. 

User-Created Formats 

The GEMCOS Format Library inter£eu:e enables us^s to create message formats by 
using ALGOL, COBOL(68), or COBOL74. These formats are maintained in addition to 
the standard TCL formats. AH the user-created formats must be maintained in one 
format library. The title of the format library must be specified in the global section of 
the TCL file. If no title is specified, the defoult title is GEMCOS/FOBMATLIBEARY. 

Using the Format Support Library 

All GEMCOS formats for input, output, forms requests, paging, and library are retained 
in COMS throi^ the use of the format support library (FS-LIB). 

The following paragraphs discuss various aspects of the FS-LIB. 

Using the Format Support Library In Agendas 

The FS-TiTB must be included in an agenda to perform input or output formatting, a 
forms request, or paging. If SDF processing items are also used, the SDF processing 
items must be included after the FS-LIB. 

When an agenda is used for output formatting, the agenda should not be designated as 
the default output s^enda for that window. Otherwise, a stack overflow error could 
occur when the FS-LIB attonpts to report errors to the monitor stations. 
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Formatting Performance Expectations 

Using the FS-UB instead of GEMCOS could improve your system's formatting 
performance because the library nms as part of the COMS multiprogramming 
environment, whereas GEMCOS uses single-streamed formatting. At minimum, your 
^tem should format as efficiently using the FS-LIB as it does using GEMCOS. 

Logical Flow for Input and Output Formatting 

When input or output formatting is required, the format support library follows the basic 
Ic^lical flow shown below: 

1. Determines the window where the message was entered or is being sent and locates 
the appropriate TCL system. 

2. Gets the device type for the station where the input message was entered or where 
the output message is to be sent. 

3. Searches for the proper format usang the system index, the device type, and either 
the format ID or message k^. 

4. Establishes parameters and calls the formatter routine to format the message. 

5. Exits. 



Logical Flow for Forms Request 

When a forms request is entered, the FS-UB varies the basic logical flow. Steps 1, 2, and 
5 of a forms request are the same steps used for input and output formatting. Steps 3 
and 4 are different. 

1. Determines the window where the message was entered or is being sent, and locates 
the appropriate TCL i^rstem. 

2. Gets the device type for the station where the input message was entered or where 
the output message is to be sent. 

3. For input messages with lengths less than or equal to sbc characters, searches among 
aU message IDs to see if the user is requesting a form. 

4. Fot a forms request, sends the form to the requesting station. 

5. Exits. 
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Logical Flow for Paging 

When a user application program sends a message that requires paging, the basic logical 
flow followed by input and output fonnattix^ is initiated. At step 4, the FS-LIB calls 
paging routines to process the message. Steps 4, 5, and 6 are directed 1^ the pagii^ 
routines. 

1. Determines the window where the message was entered or is being sent, and locates 
the appropriate TCL system. 

2. Gets the device lype of the station where the input message was entered or where 
the output message is to be sent 

3. Searches for the proper format using the system index, the device type, and either 
the format ID or message key. 

4. For pe^d formats, calls ps^ing routines to send the first screen to the device and to 
prepare for paging dialog. 

5. For an update p£^ed format, when the user sends the paging complete character 
(X), sends the entire formatted message to COMS as a new input. 

6. Exits. 

Formatting is then handled by pagii^ routines until the paging mode is exited. 

With the FS-LIB, there is no restriction on the number of stations that can use pagii^ at 
one time even if GEMCOS contirol pagii^ is specified in the TCL. 

Creating the COMS Environment 

To produce the correct formatting, the format support libraiy (FS-LIB) requires the 
following COMS entities: 

• Windows 

• Trancodes 

• Device types 

• Libraries 

• Processing items 

• Processing-item lists 

• Agendas 

Create these entities throu^ the COMS Utility before using the FS-LIB. (See the 
''GEMCOS Sources for COMS Entities and Attributes" sqipendix for a listing of 
GEMCOS and COMS counterparts.) 

Because of the importance of the COMS entities listed above to the FS-LIB, information 
about defining them to COMS is presented in the paragraphs that follow. The COMS 
Utility command for creating each of these entities is included. Also presented is 
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information about updating formats, amending application programs to use the COMS 
direct interface, recognizing input formatting errors, and obtaining monitor output. 

Creating COMS Windows for Systems in the GEMCOS TCL 

It is possible for more than one COMS direct- window to access all the formats of the 
FS-IJB. This capabiUty is accomplished by setting the GEMCOS s^obal attribute 
MASTERCOMPUTB to TRUE and having only one system declared in the GEMCOS 
TCL. Then the FS-IJB accepts any format request firom more than one COMS direct 
window. 

However, you mig^t want to restrict format requests to specific windows. If 
MASTERCOMPUTE is equal to FALSE, or if there are multiple ^tems in the TCL, 
access to the FS-LIB is established as follows. 

For every system in the GEMCOS TCL for which you want to use formatting in COMS, 
create a window with the same name as the system. In the TCL, at least one program 
must be declared in a system. All message keys for a system must be declared imder 
that program. 

The COMS Utility command for creating a window is the following: 

CREATE WINDOW <window name> 
A window name can be 1 to 17 alphanumeric characters. 

Defining Trancodes 

The COMS Utility command for defining a trancode to COMS is shown below. Ensure 
that the trancode (message k^) firom the TCL matches the input in the command. 

CREATE TRANCODE <trancode nanie> OF <w1ndow naine> 
AGENDA » <a9enda name> 
FUNCTION = <integer>; 

A trancode name and a window name can be 1 to 17 alphanumeric characters. An 
agenda name can be 1 to 17 alphanumeric characters and must begin with a letter. The 
integer for FUNCTION can be a number from 0 (zero) to 9999. 

Note that all trancodes must start in position one of the input. 

Notes The FS-LIB discontinues (OSes) the task if a conversation area is not 
allocated in the leader of the program. 

Defining Device Types 

The COMS Utility command for defining a device type to COMS is shown below. Ensure 
that the device declared in the TCL matches the input in the command. 
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CREATE DEVICE_TYPE = <device_type name>; 
CREATE STATION <station name> 

DEVICE^TYPE = <device_type name>; 

A device type name can be 1 to 17 alphanumeric characters and must begin with a letter. 
A station name can be composed of up to 12 nodes. Each node must start with a letter 
or a ntmiber, followed by up to 16 additional characters. These succeeding characters 
can be letters, numbers, underscores (J, or hyphens(-). The station name can be a 
ma^miini lei^;th of 255 characters. 

Defining Processing-Item Libraries 

In COMS, a library contains a set of procedures called processing items. These items can 
be called by agendas to process messages before or after input or output. A library name 
must be ass^ed to each processing item defined in the configuration file. 

The COMS Utility command for defining a processing-item library to COMS is shown in 
the foUowii^ 

CREATE LIBRARY <library nanie>; 

A library name can be 1 to 17 alphanumeric letters and must begin with a letter. 

You can have multiple copies of the FS-LIB to process different TCL files. Each 
copy must be a separate copy of the code file, and each can have one GEMCOS 
FORMATLIBRARY 

Defining Processing Items 

The processing item ACTUALNAME must be TCL^FOBMATTBR. It must be associated 
with a previous^ defined processing-item library. 

The COMS Utility command for defining a processing item to COMS is shown in the 
following: 

CREATE PROCESS I NG_ITEM <proces sing-it em name> 
ACTUALNAME~« TCL_FORMATTER, 
LIBRARY « <library name>; 

A processing-item name and a library name can be 1 tol7 alphanumeric letters and must 
be^ with a letter. 

Creating Processing^ltem Lists 

The processing-item list contains the processing items to be called by the agenda before 
it processes the message. The order in which the processing items appear in the list is 
the order in which they are called. If the FS-LIB is used in coi^unction with SDF, the 
SDF processing items must follow the FS-LIB processing item. 



8600 1567-000 



3-7 



Format Support Library 



Include the FS-T.>TB in an agenda's processiii^-item list when any input or output 
formatting, forms request, or paging is required. Include it in the default agenda for 
vrindows that mig^t use paging. When COMS encounters invalid trancodes, such as 
poffBg dialog characters, the default agenda is invoked. 

The COMS Utility command for creating a processing-item list is shown in the following: 

CREATE PROCESSINGJTEM_LIST 

<processi*ng_itera_list name> « 

<process1ng_1tem namel, nameZ, naroe3,...>; 

A processing-item list name can be 1 to 17 alphanumeric characters and must begin with 
a letter. 



Using Agendas When Formatting 

A COMS agenda processes and routes messages on input, output, or both, for direct 
windows. To use an agenda on input, the agenda must have an assigned destination 
program. Form requests and pagii^ dialog messages, however, do not go to the 
destination program. The destination is specified either in the output header of the 
message or in the output header of the application program. By default, the destination 
is assumed to be the input station. 

To use update paging with a particular window, the window must have an additional 
agenda created with INPUT_ROUTER as its destination. This agenda must have the 
same name as the window and the GEMCOS TCL system. 

The COMS Utility command for defining an agenda to COMB is shown in the following: 

CREATE AGENDA <agenda name> OF <window name> 

PR0CESSIN6_ITEM_LIST = <processing_UemJist naine>, 
DESTINATION » <program name>; 

An agenda name, processing-item list name, and a program name can be 1 to 17 
alphanumeric characters and must begin with a letter. A window name can be 1 to 17 
alphanumeric characters. 

Updating Formats 

To update formats, run the GEMCOS Utifity agednst the TCL. Then disable t^^ 
fay entering the following command: 

?DISABLE LIBRARY <library name> 

For more information about updating formats, refer to the COMS Operations Guide. 
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Amending Application Programs 

Application programs must be amended to use the COMS direct interface. This means 
that for output formats, the FOBMID must be placed in the first six bytes of the COMS 
conversation area. 

Recognizing input Formatting Errors 

Input formatting (station to program) errors are reported to the application program 
by the conversation area. If a format error occurs, the second word of the COMS 
conversation area is set to 1. If a program's conversation area is less than two words 
tox^, input formatting errors are not reported to that program. 

Obtaining IVIonitor Output 

The FS-TjTB sends format exception notification to the COMS monitor stations. This 
notification is directed to the window on the monitor station that corresponds to the 
window on which the exception occurred at the user station. Thus, if notification is 
desired, the monitor station must have the same window name (the GEMCOS system 
name) declared, and that window must be open. 

What the GEMCOS TCL File Must Contain 

The GEMCOS TCL file must be compiled, without any syntax errors, with the 
GEMCOSAJTILITY; release 8.0 or h^er. (A Series GEMCOS users need not recompile 
their TCL. The format support library (FS-LEB) can be used with existing GEMCOS files 
as long as the files were generated hy the GEMCOS/UTILITY; release 8.0 or higher.) If 
the release levels are incorrect at run time, an error is displayed and the FS-LIB goes to 
end of task (EOT) without being used. 

The FS-TiTR needs information firom the device and format sections in the GEMCOS 
TCL fiOie. In addition, it needs to know the system names defined in the TCL file so 
that the correct format can be applied according to which window the user is on. (This 
information is obtained fi*om the files produced by the GEMCOSAJTILITY.) 

The following files must be file-equated when the GEMCOSAJTILITY is run. The 
variable < codefile name > is the code file name of the FS-LEB. These files must have a 
security classification of PUBLIC lyO. 



GEMCOS nie File-Equated to 

IQUS <codefile name>/INPUT 

OQUS <codefile name>/OUTPUT 

CQUS <codefile name>/CONTROL 

FMTFILE <codefile name>/FORMAT 
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The COMS FS-LIB provides that all the formats in a GEMCOS TCL file are made 
RESIDENT if PAGINGPERMANENT is assigned the value TRUE in the global section 
of the TCL file. If you have been running GEMCOS with PAGINGPERMANENT 
as TRUE to keep the GEMCOS PAGER stack in the mix, you should consider that 
PAGINGPERMANENT has a different function when running through COMS. You 
might want to assign the value FALSE to PAGINGPERMANENT if you do not want all 
formats to be RESIDENT. 
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GEMCOS Windows 



This section presents guidelines for running the Generalized Message Control System 
(GEMCOS) in a Communications Management System (COMS) message control system 
(MCS) window, and considers various aspects of GEMCOS operation through COMS. 
The section indicates limitations to GEMCOS features when GEMCOS is operatix^ with 
the CP 2000 front-end processor through COMS. 

The information in this section pertains specifically to running GEMCOS in a COMS 
MCS window. For information about a COMS MCS window in general, refer to Section 
2. 

The followii^ topics are presented in this section: 

• General description of a GEMCOS window 

• Advantages of running GEMCOS through COMS 

• Changing station names in GEMCOS transaction control language (TCL) 

• Entering control and system commands 

• GEMCOS feature limitations with the CP 2000 

• Relative GEMCOS functional behavior with the CP 2000 and the network support 
processor (NSP) 

Unless indicated otherwise, the information in this section applies to GEMCOS 
operating either with the CP 2000 through COMS or with the network support 
processor (NSP) thrdu^ COMS. Note that the information in this section under 
''GEMCOS Feature Limitations with the CP 2000" applies only to GEMCOS operating 
with the CP 2000 throu^ COMS. 



General Description of a GEMCOS Window 

An MCS window that is used to run GEMCOS through COMS is called a GEMCOS 
window. 

The Kernel version of COMS enables a station to have one dialog of the GEMCOS 
window. 

The full-featured version of COMS provides a means to define a GEMCOS window that 
allows multiple simultaneous dialogs with GEMCOS at a station, once the GEMCOS 
system has been installed on the network. Such window definition is accomplished 
throu^ the COMS Utility program, as described in the COMS Configuration Guide. A 
GEMCOS window can be defined to allow a maximum of e^t simultaneous dialogs with 
the GEMCOS system at a station. 
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A number of GEMCOS \vindows can be defined through the COMS Utility. If the 
network is to include more than one GEMCOS system, a GEMCOS window can be 
defined and established for each of the systems. 

Advantages of Running GEMCOS through COMS 

A distinct advantage of running GEMCOS throu^ COMS, rather than running 
GEMCOS direct^ under the NSP — or directly under the data communications data 
link processor (DCDLP) — is your ability to have multiple simultaneous dialogs with 
GEMCOS. This ability allows efficient use of a terminal 

Another advantage of running GEMCOS through COMS is the convenient menu-driven 
transaction-processing facility provided to COMS users by the Menu-Assisted Resource 
Control (MARC) program. For information about the MARC program, refer to the 
MARC Operations Guide. 



Changing Station Names in GEMCOS TCL 

When GEMCOS is installed on the same network with COMS, and a GEMCOS window 
is defined through the COMS Utilily program, the names of the stations in the TCL 
for the GEMCOS-controlled environment must be changed. The reason for changing 
the names of these stations is to make the names compatible with the COMS naming 
convention for pseudostations. In other words, the name of each station in the TCL 
must be made the same as the name of the corresponding pseudostation allocated in 
COMS so that GEMCOS can identify which pseudostations it can communicate with and 
control 

For One Dialog 

To be compatible with the COMS naming convention for pseudostations, you must 
change the Network Definition Language n CNBLID name of each station in the TCL to 
reflect the following information and format: 

<NDLII station name>/<MCS window haine>/<d1a1og number> 

This chai^ typical]^ involves adding a window name and dialog number to each of the 
station names that already exist in the TCL. For example, assume that the TCL includes 
a station named STAl. If an MCS window named GEMCOS were declared for station 
STAl through the COMS Utilily, it would be necessary to change the name of the station 
to STAl/GEMCOS/1 in the TCL. 

For More Than One Dialog 

To use more than one dialog, you duplicate the description of STAl/GEMCOS/1 in the 
TCL as many times as required, and make the corresponding dianges to the dialog 
number. 
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For example, to use three dialogs from the station, you duplicate the description of 
station STAl/GEMCOS/1 in the TCL two times, and change the dialog number to 2 and 
3. The result is three stations declared in the TCL (instead of the former single station 
STAl). You must also make all changes to device type and other areas in the TCL for 
the two new stations, to correspond to the way the original station was declared in the 
TCL. Consider that GEMCOS views each dialog as a different station, and makes no 
association between dialogs. 

When GEMCOS is installed, a GEMCOS window is defined, and the station names are 
changed in the TCL, you then can have a number of simultaneous dialogs with GEMCOS 
at your station. 

Entering Control and System Commands 

The following information is provided to help a station user communicating through a 
GEMCOS window enter control commands directed to COMS or GEMCOS. Information 
is also provided to help a system user who is communicating through a GEMCOS window 
enter system commands. 

When GEMCOS is operating with the CP 2000 throiigh COMS, data comm network 
control for GEMCOS is handled by COMS instead of by GEMCOS. Therefore, refrain 
firom using GEMCOS commands to manage the network; instead, use the corresponding 
COMS commands. 

When GEMCOS is operating with the NSP throu^ COMS, data comm network control 
for GEMCOS is stiU handled by GEMCOS. Therefore, you can use GEMCOS commands 
to control parts of the network. Refer to ''Bequirements for an MCS to Function 
throi^ COMS** in Section 2 for information. 

You can enter GEMCOS commands not associated with network control at any time 
while you are communicating throu^ a GEMCOS window, whether COMS is operating 
with the CP 2000 or the NSE 

To direct a conmiand to COMS from a GEMCOS window, ^ter the command prefixed 
by one question mark (?). To direct a command to GEMCOS from a GEMCOS window, 
enter the command prefixed by two question marks (??). To enter a i^stem command 
from a GEMCOS window, enter the comiDand prefixed fay three question marks (???). 

Be sure to prefix your command with the correct number of question marks. 

If you enter a command prefixed by one question mark (?), COMS attempts to handle 
the command, even if it is a GEMCOS command. If COMS imderstands the command, it 
handles it If not, it passes the command to GEMCOS. 

GEMCOS handles all commands prefixed by two question marks (??). Therefore, to 
ensure that GEMCOS handles a command, enter it prefixed by two question marks 
(??). For example, both COMS and GEMCOS have a STATUS command. If STATUS 
is prefixed by one question mark (?), COMS responds with the status. If STATUS is 
prefixed two question marks (??), GEMCOS responds with the status. 
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Note that a command like CHANGE is alwajrs handled by GEMCOS, whether prefixed 
one or two question marks. Since there is no CHANGE command in COMS, COMS 
gives the CHANGE command prefixed by one question mark (?) to GEMCOS. 



GEMCOS Feature Limitations with tiie CP 2000 

Operating GEMCOS with the CP 2000 throu^ COMS entails a nimiber of limitations to 
GEMCOS features. These limitations are described in the following paragraphs. 



Limitations Due to Loss of Toggles and Tallies 

Toggles and tallies are the station-oriented variables in the NDLII program. When 
GEMCOS is operating either direct^ under the NSP or with the NSP through COMS, 
GEMCOS uses toggles and tallies to communicate with the NSP 

The CP 2000 has built-in request sets and does not recognize toggles and tallies. 
Therefore, GEMCOS cannot use toggles and tallies when it is operating with the 
CP 2000 through COMS. 

The inability of GEMCOS to use tog^es and tallies when it is operating with the 
CP 2000 through COMS results in the following limitations to GEMCOS features: 

• The STAMASTER attribute in the station section of the GEMCOS TCL is not 
supported. Since GEMCOS can no longer use the STAMASTER attribute to 
designate a station to be a master station,' no computer connection that uses the 
STAMASTER attribute is 8i:^ported. 

• If an otrject job is used, all stations to which the otgect job is attached must have 
MYUSE equal to 3 (that is, all stations must be input- and output-capable). 
GEMCOS is unable to inform the NSP that it is sending a message to a 
network-control station on otigect job output 

• The BROADCAST attribute in the station section of the GEMCOS TCL is not 
supported Therefore, GEMCOS cannot use the BROADCAST attribute to instruct 
the NSP to broadcast a message to all stations on a line. Note that a message can 
still be broadcast to all stations on a line, but the message is sent to each station one 
at a time rather than simuttaneousfy to all stations. 

• When the MSG-QBYPASS bit (COMMON[7].[46:l]) is assigned the value 1 by a 
user prc^pram, the output messe^ is not audited. Uni^ recommrads that the 
MSG-QBYPASS bit (COMMON[7].[46:l]) be equal to 0 (zero). If the bit is equal to 
1 and a station gives negative acknowledgment (NAK) to an output message, the 
message is lost. 

• The NOQUEUE attribute in the station section of the GEMCOS TCL is not 
supported. 
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Other Limitations 

When GEMCOS is operating with the CP 2000 through COMS, limitations to GEMCOS 
features other than the limitations due to the loss of toggles and tallies are the following: 

• The NOLINE and IDENTIFY attributes in the station section of the GEMCOS TCL 
are not supported because COMS, and not GEMCOS, handles the dial-in stations. 
Therefore, you cannot use a dial-in station to dial in to GEMCOS. 

• The LOGICALACK attribute in the station section of the TCL in GEMCOS is not 
supported. Therefore, GEMCOS cannot use the NSP LOGICALACK Gogical 
acknowledgement) function. 

• The SETMCSREQUESTSET attribute in the station section of the GEMCOS TCL 
is not supported. Therefore, GEMCOS cannot use the SETMCSREQUESTSET 
attribute to instruct the NSP to switch between request sets. 

• Process programs associated with GEMCOS are no longer able to issue network 
control commands to GEMCOS to control the data conmi network. In this respect, 
the process programs are limited in the same way that station operators are limited 
in the ability to control the network. All network control is handled by COMS. 

Relative GEMCOS Functional Behavior with CP 2000 
and NSP 

Because of the limitations described under '^GEMCOS Feature Limitations with the 
CP 2000" in this section, GEMCOS operating with the NSP throu^ COMS is expected 
to perform more fimctions and provide more results than GEMCOS operating with the 
CP 2000 through COMS. However, GEMCOS operating with the CP 2000 through 
COMS is still expected to have most of the capabilities of GEMCOS operating with the 
NSP through COMS. 

Further, GEMCOS operating with the NSP through COMS is expected to have almost 
all the capabilities of GEMCOS operating directly under the NSP 
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Section 5 
Remote Files 



This section compares the handling of remote files through the Commtmications 
Management System (COMS) with the handling of remote files through the Command 
and Edit (CANDE) SQrstem. CANDE uses logical I/O to handle remote files, while COMS 
also has extensions for the window handling. Emphasis is placed in this section on how 
COMS handles remote files. 

For a detailed discussion of remote files in a COMS environment, refer to the COMS 
Programming Guide and the COMS Configuration Guide. 

What is a Remote File? 

A remote file is a file with a KIND attribute specified as REMOTE. A remote file enables 
obgect programs to conmiunicate interactively with a data conmi station. 

You typically use a remote file when you want to dedicate a program to a certain user. A 
remote-file program characteristically involves data entry or inquiry on records firom a 
station. 

Situations for Using Remote-File Windows 

In operating imder COMS, there are basica% two situations in which you would consider 
using r^ote-file windows: 

• If you have existing programs that use an existing remote-file interface 

• Kyou want to dedicate a program to a certain user 

Comparison of COMS and CANDE Remote-File 
IHandilng 

If you are operating under CANDE and execute a remote-file program, the remote-file 
program declares a remote file that by default works onfy with the single station that it 
rec(^nizes. In other words, a remote-file program executed tmder CANDE can have only 
one user, unless it e^qplidtly takes action to add more stations to its remote file. Separate 
copies of the program are needed for other users. 

Under COMS, on the other hand, you can have remote files that accommodate a number 
of stations (multistation remote files) as well as sin^e-station remote files. 

When you run a remote-file program under CANDE, either in a CANDE window under 
COMS or through CANDE directly controlling your real station, the remote file takes 
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over the station, and aU input except control commands is routed to the remote file. This 
is also true if you run a remote-file program outside of CANDE— for example, through 
Work Flow Language (WFL) —provided the remote file is label-equated to your station. 

When you run a remote-file program under COMS, either by running it in the 
Menu-As^ted Resource Control (MARC) interface or by running it outside of 
COMS/MARC vtrith the remote file label-equated to your station, COMS creates for it a 
dynamic remote-file window called ^REM < nimiber > " When the program is run from 
MARC, you can ''move" to the remote file either by specifying TASK as a command to 
MARC or by specifying the following: 

?0N REM<number>/<dialog number> 

When the program is run outside of COMS/MARC, you have only the option of entering 
"TON REM < number > / < dialog number > .** When the dynamic remote-file window is 
the current window, aU input except control commands is routed to the remote file. 

A program that runs in CANDE can typically nm imder COMS as a dynamic remote-file 
program without any change. 

Note that operating a remote-file program firom a station under CANDE in a COMS 
MCS window is no dififerent from operating a remote-file program from a station 
controlled direct^ by CANDE. 

Dynamic and Declared Remote Files 

CANDE handles only (fynamic remote files. COMS handles both (fynamic remote files 
(that is, not defined to COMS) and declared remote files (that is, defined through the 
COMS Utility). Under COMS, (fynamic remote-file programs are not shared. However, 
declared remote-file pn)gram8 can be shared as defined through the COMS Utility. 

A declared remote-file window is a window defined for an associated remote-file program 
through the COMS Utility. A declared remote-file program can handle either one station 
or a nimiber of stations. The number is specified through the COMS Utility. Specific 
logic is normally required in the program to handle more than one station. A program 
that runs in CANDE can run under COMS as a declared remote-file progrmn, but th^ 
declared program typically is not written to handle more than one station. 

Note that if a remote-file program rec^ves parameters or requires a run-time file 
equation or task equation, it cannot be used as a declared remote-file program under 
COMS. Moreover, r«aDU)te-file programs that access atMbutes of the remote file might 
require modifications to work property as declared remote-file programs. 
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Multistation Remote Files 

Under CANDE, a remote-file program can access more than one station in a remote 
file by either of two means. It can add stations to the file and subtract stations from 
the file by using the STATIONLIST file attribute as described in the J/O Subsystem 
Programming Guide, or it can open a file using a title of a file described in the 
installation Network Definition Language n (NDLH). 

When COMS is used, a multistation remote-file program does not have to use 
either of the means indicated above to add and subtract stations. COMS does all 
the necessary adding and subtracting. When you first access the window (using 
?0N < declared remote-file window > ), COMS adds the station to the file without help 
fi-om the program. When you close the window (using 7CL0SE or by logging off) COMS 
subtracts the station from the file. In this case, the remote-file program is informed of 
the closure by getting an end-of-file (EOF) indication for the relative station number 
(SSN) of the station. 



Input Remote Files 

Under CANDE, you can have only one input remote file. Under COMS, you can have 
more than one input remote file, each in a separate dynamic remote-file window. 

Defining and Executing Declared Remote-File Programs 

Because CANDE handles only dynamic remote files, you cannot define remote-file 
programs throt^ CANDE. 

Through the COMS Utility, you can define certain remote-file programs to COMS, 
induding user-written pn^^raois that meet sample restrictions. You can then ass^ 
these programs tmique window names, and make the windows available to aU or 
selected users. These are declared remote-file windows, A user can then specify 
?0N < name of declared remote-file window > and execute the program For 
information on how declared remote-file windows are defined throu|^ the COMS Utility, 
refer to the COMS Configuration Guide. 



Executing a Remote-File Program by a RUN Command 

In a COMS environment, any d3niamic remote-file program that you execute by a RUN 
command ieom a CANDE window or a MARC window opens a remote file to your 
stati(m that shares the original window. No remote-file window is involved for programs 
executed in this manner. 
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Closing a Remote File 

Under COMS, remote-file programs receive an end-of-file (EOF) indication on their 
remote files whenever the window associated with the program is closed. If the 
LASTSUBFTIjE file attribute is interrogated at this point, it specifies the relative station 
number (RSN) of the station removed from the remote file to indicate that CLOSE has 
occurred for that station. Declared remote-file programs receive an additional EOF 
indication when COMS instructs the program to go to end of job (EOJ). In this case, the 
LASTSUBFILE attribute is assigned the value ''BSNl". This occurs when all users 
have closed a remote-file window and the minimimi number of copies for that program 
has been exceeded. 

The following program firagment is an example of the statements that might be used in 
a multistation remote-file program written in ALGOL and running under COMS. The 
fragment shows how the program handles an EOF on its remote file when the window 
associated with the program is closed. 

DEFINE 
ERROR_FUG = [0:1] #, 
EOF_FLAG = [9:1] #; 

WHILE TRUE 00 
BEGIN 

READBOOL :» REAO(RMT, 288, IN.BUF) ; 
IF NOT REAOBOOL.ERROR FUG THEN 

PROCESS JNPUT(IN.BUF) 
ELSE 

IF READBOOL.EOF FUG THEN 
IF RMT.USTSUBFILE » 1 THEN 

WRAP UP PROGRAM 
ELSE 

HANDLE CLOSE_OF-STATION 
ELSE 



END; 

The following program fragment is an example of the statements that mig^t be used in a 
remote-file program written in COBOL and running under COMS. The firagment shows 
how the program handles an EOF on its remote file when the windcm associated with 
the program is dosed. 
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77 LAST-STA-SW PIC 9 VALUE 0. 

88 LAST-STA VALUE 1. 

MAINLINE. 



• 

PERFORM RECEIVE-INPUT THRU RECEIVE-INPUT-EXIT 

UNTIL LAST-STA. 
PERFORM WRAP-UP-PROGRAM. 
STOP RUN. 

RECEIVE-INPUT. 
READ RMT; 
AT END 

PERFORM HANDLE-EOF 
GO RECEIVE-INPUT-EXIT. 
PERFORM PROCESS- INPUT. 
RECEIVE-INPUT-EXIT. 
EXIT. 

HANDLE-EOF. 

IF AHRIBUTE USTSUBFILE OF RMT = 1 THEN 

MOVE 1 TO LAST-STA-SW 
ELSE 

PERFORM HANDLE-CLOSE-OF-STATION. 



Tanking 

Logical I/O, which is used by CANDE, does all the tanking for a remote file on a file basis. 
COMS, on the other hand, does all the tanking on a dialog basis for each station in a 
remote file. This means that COMS cannot apply the same niles for suspending output 
as logical I/O does. Logical I/O allows as many outstanding messages as there are file 
buffers for the file before suspending output. COMS allows 2400 characters per station, 
including data comm headers, to be outstanding. 

Handling of Time Limit on a Write Operation 

Time-limit handling by logical I/O differs from time-limit handling by COMS. Logical I/O, 
which is used by CANDE, gives a time-limit exception when no file buffers are available 
for the write operation for the specified time period. Except as noted below, COMS 
gives a time-limit exception when the number of outstanding characters for a station has 
exceeded the limit of 2400 for the specified time period. 

Note that if a broadcast write operation is done, COMS gives a time-limit exception only 
if no station in the remote file has been sent output. 
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Direct I/O 

Direct I/O on remote files is supported by logical I/O only if the controlling MCS, typically 
CANDE, controls the network support processor (NSP) stations directly. Direct I/O on 
remote files is not supported by COMS, nor is it supported in a COMS MCS window. 

If a program that uses direct I/O on remote files is run in a COMS remote-file window, 
COMS handles the remote file as if it were a nondirect file with tanking set to ASYNC. 
In handling this I/O on the pseudostation for the MCS window, the operating system 
completes the VO when COMS gets the transaction, not when the transaction is sent to 
the terminal 
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Comparing GEMCOS to COMS 



Appendix A consists of seven tables that compare the functions and features supplied 
by the Generalized Message Control System (GEMCOS) with those provided in the 
full-featured Conmiunications Management System (COMS). 

Each table compares one functional area. The tables are presented in alphabetical order: 

Table A-1. Application Program Inter&ce 
Table A-2. Computer-to-Computer Communication 
Table A-3. Environment InterfSace 
Table A-4. Message Formatting 
Table A-5. Recovery 
Table A~6. Security 
Table A-7. Station Interface 



Within each table, the feattires are listed alphabetically. Aspects of the feature are 
shown in alphabetical order. 

Several GEMCOS features, while not supplied in COMS, can be implemented through 
a processing item or station list. When applicable, methods for implementing these 
features are noted in the tables. 
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Table A-1 compares the application program interface of GEMCOS to COMS. 



Table A>1. Application Program Interface 



GEMCOS Feature 


COMS Feature 


Batch job interface 


No. (Synchronized recovery with batch jobs is 
available outside COMS.) 


Conversation areas 


Yes. (Available on input to the program from a 
processing item.) 


Editor program 


No. (Can be implemented tiy a user-created 
processing item.) 


Module/function indexes 


Yes 


Multiple input queues per program 


No 


Multiple transactions per execution 


Yes 


Object job interface: 




Program 


No 


Station 


Yes 


Practice mode 


No 


Priority scheme for input queues 


No 


Program initiated tiy NOINPUT command 


No 


Program can specify TITLE on output to 
indicate message sent to multiple 
stations. 


No. (Can be implemented by a user-created 
processing item or a station list.) 


Retry counter for Transaction Processor 
(TP) failure 


Yes 


Sending multiple output messages per 
transaction 


Yes 


Sending/receiving parts of messages 


No. (Can be implemented by a user-created 
processing item or a station list.) 


Service program 


No. (Can be implemented tiy a user-created 
processing item or a station list.) 


Single transaction per execution 


No 


Station bits 


Yes. (COMS installation data feature provides the 
same functionality.) 


Test program 


No 



continued 
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Table A-1. Application Program Interface (cent.) 



GEMCOS Feature 


COMS Feature 


Transaction-based routing as follows: 




Pmoram-tn-nroffram r&snonse to 

program 


No fCan lv> imnlpmpntpri h\/ a iKPr-rn>$itpd 

I^Wa \WVll Uw III Ipld llwllLCU UJ O Udwl^#lwaiiCW 

processing item.) 


Station 


Yes 


Station to program 


Yes 


User-supplied routing 


No. (Can b& implemented by a user-created 
processing item.) 


Transmission of messages to the 
following: 




Area broadcast 


No. (Can be implemented by a user-created 
processing item or a station list.) 


Area rotary 


No 


Monitor station 


No. (Can be implemented by a user-created 
processing item or a station list.) 


Network control station 


No. (Can be implemented by a user-created 
processing item or a station list. 


Originator 


Yes 


Prooram hu niimhpr 




Program by trancode 


Yes 


Station by name 


No. (Can be implemented a user-created 
processing item or a station list.) 


Station t)y number 


No. (Can be implemented tiy a user-created 
processing item or a station list.) 


Stations by output message ID 


No. (Can be implemented by a user-created 
processing item or a station list.) 


Validation of area name 


No 


Validation of station name 


Yes 
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Table A-2 compares GEMCOS features to COMS features in a computer-to-computer 
communication. 



Table A-2. Computer-to-Computer Communication 



GEMCOS Feature 


COMS Feature 


GEMCOS-to-GEMCOS file transfer 


No 


Routing headers for the following: 




Station GEMCOS-to-GEMCOS communication of 
transactions and output messages 


No 


Station as port file 


No 


Station that is port file 


No 


Transaction-t}ased routing station to station t>y trancode 


No 



A-4 
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Table A-3 compares GEMCOS features to COMS features in an environment interface. 



Table A-3. Environment Interface 



GEMCOS Feature 


COMS Feature 


nuiTiinisiiaiive message swncning 


INO 


v/UMrU 1 C COmmanG 


INO 


Control of the follou/inff* 




Database nrosranns 


Yes 


Soecified stations 


Yes 


Dynamic volume 


Yes 


Interception of station message traffic 


No. (Can be implemented by a user-created 
processing Item.) 


Limitation of memory for program input 


Yes 


Memorv stjbs\/stem control for the foilOM/inff* 




Message coniioi sysiein viviwo/ 


viae /^nK/ fnr rlstoh^cA /^/%ntr/^l \ 

Tcs. luniy Kjr uaiaoase coniroi.^ 


Programs 


Vac 

yes 


Output message for the following: 




Refresh 


No. (Can be implemented by a user-created 
processing item.) 


Recall 


No. (Can be implemented by a user-created 
processing item.) 


Placing station out of service for 15 minutes 


No 


Program in mix can be the following: 




Permanent in mix 


Yes 


Temporary in mix 


Yes 


Restricting commands from user-supplied 
program 


Yes 


Station alternates 


No. (C^n be Implemented by a user-created 
processing item.) 


Statistics 


Yes 
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Ted>le A-4 compares the message formatting features of GEMCOS to COMS. 



Table A-4. Message Formatting 



GEMCOS Feature 


COMS Format Support Library Feature 


Brankfili 


Yes 


Data translation [FUNCTION] 


Yes 


Forms composition 


Yes 


Input formatting by trancode 


Yes 


Item count passed to program 


Yes 


Numeric editing 


Yes 


Numeric verification and zero fill 


Yes 


On-line updating of formats 


Yes 


Output formatting t>y device type and output 
message ID 


Yes 


Paging: 




Input 


Yes 


Output 


Yes 


Paging breal(s 


Yes 


Repeat paging 


Yes 


Total lines 


Yes 


Update 


Yes 


Variable format 


Yes 


Updated formats available in practice mode 


No 


User fonnatting of MCS responses 


No. (Can be implemented by a user-created 
processing item. Note that all COMS 
message control system (MCS) messages go 
through the Menu-Assisted Resource Control 
(MARC) interface, and MARC has 
Multilingual System (MLS) capabilities to 
translate the language.) 


User-supplied formatting routines 


Yes 


Variable length of items 


Yes 


Variable repetition of items 


Yes 


friable sequence of items 


Yes 



A-6 
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Table A-5 compares the recovery feattires of GEMCOS to COMS. 



Table A-5. Recovery 



GEMCOS Feature 


COMS Feature 


Archival recovery 


Yes 


Audit of input messages 


Yes 


Audit of input messages by trancode 


Yes. (Auditing done by database.) 


Audit of output messages 


No. (C^n be implemented by a 
user-created processing item.) 


Audit of output messages tjy prc^ram action 


No. (Can be implemented by a 
user-created processing item.) 


DMSII: 




Recovery of program-to-program 
response to program messages 


No 


Recovery of program-to-program 
response to station messages 


No 


^nchronized recovery 


Yes 


Nonrecovery of messages 


Yes 


Recovery of output message before entering Data 
Management System II (DMSII) transaction state 


No 


Recovery for batch job feeding transaction 
programs 


Yes 


Recovery transparent to program 


Yes 
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Table AS compares the security features of GEMCOS to COMS. 



Table A-6. Security 



GEMCOS Feature 


COMS Feature 


Continuous log-on 


Yes 


Dial-in stations required to identify 


No 


Identifier passed to programs 
[INDIVIDUALID] 


Yes 


Multiple users per station 


No 


Station able to switch t)etween application 
systems 


Yes 


Station limited to trancodes for application 
system 


Yes. (Usercode limited to windows.) 


Usercode (no password) 


Yes. (Usercode with password.) 


User-supplied access control package 


No. (Can be implemented by a user-created 
processing item.) 


Valid trancodes for usercode 


Yes 


Valid usercodes for station 


Yes 


Table A-7 compares the station interface of GEMCOS to COMS. 


Table A'7. Station Interface 


GEMCOS Feature 


COMS Feature 


Acknowledgement of input messages as follows: 




LOQICALACK tiy message control system 
(MCS) 


Yes. (Not on CP 2000 stations.) 


PROGRAMACK by program 


No 


Fixed length of trancodes 


Yes 


Limit of one transaction at a time 


Yes 


Return to MCS defined tjy Network Definition 
Language II (NDUl) at end of job (EOJ). 


Yes 


Select tailored date comm software. 


No 


Specify location of trancode in message. 


Yes 


Title on output messages 


No. (Can be implemented by a 
user-created processing item.) 
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Appendix B 

GEMCOS Sources for COMS Entities and 
Attributes 



An entity is a category of information. Attributes describe the entity or are components 
of the entity. For Generalized Message Control System (GEMCOS) programs to run 
directly as Communications Management System (COMS) programs, GEMCOS entities 
must be converted into COMS entities. 

The foUovnx^ list shows the GEMCOS counterpart for six COMS entities: agendas, 
programs, trancodes, device types, stations, and windows. The entities are listed as they 
appear in the COMS Utility Home Menu, where COMS entities are normally defined. 
The list shows all attributes that can be defined for that entity using the COMS Utility. 
If the attribute does not have a GEMCOS counterpart, a dash (~) appears in the 
GEMCOS column. 

Agenda Counterparts 

The following entity comparison shows the GEMCOS counterpart for the COMS entities 
associated with £^ndas. 

GEMCOS Entity COMS Entity 

INPUTQUEUE <ID> + AG Agenda name 

SYSTEM <ID> Window name 

- Default agenda 

- Processing-item list 
PROGRAM <ID> Destination 

Program Counterparts 

To alleviate migration problems and to idratify the COMS program oitity correctly, do 
the following: 

• Define the USEBCODE attribute if the TITLE attribute has a specified usercode. 

• In the FAMILY attribute, include the famify on which COMS resides. 

The following entity comparison shows the GEMCOS cotmterpart for the COMS entities 
associated with programs. 

GEMCOS Entity COMS Entity 

PROGRAM <ID> Program name 

PROGRAM TITLE TITLE 

continued 
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GEMCOS Sources for COMS Entities and Attributes 



continued 



GEMCOS Entity 


COMS Entity 


PROGRAM USERCODE 


USERCODE 


PROGRAM FAMILY 


FAMILY 


PROGRAM CHARGECODE 


CHARGECODE 


PROGRAM PRIORITY 


PRIORITY 




Valid security-category list 




Database name 




Input-queue memory size 


PROGRAM MINCOPIES 


Minimum copies 


PROGRAM MAXCOPIES 


Maximum copies 




Remote-file interface 


1st INPUTQUEUETIMELIMIT 


Time limit 


1st INPUTQUEUE QUEUEDEPTH 


Queue depth 




Remote users 



Trancode Counterparts 

The following entity comparison shows the GEMCOS counterpart for the COMS entities 
associated with trancodes. 

GEMCOS Entity COMS Entity 

MKE <I0> OF INPUTQUEUE Trancode name 

SYSTEM <ID> Window name 

INPUTQUEUE <ID>AG Agenda name 

— Security-category name 

MKE <iD>[<module><function>] Module Function Index 

Device Type Counterparts 

The following entity comparison shows the GEMCOS counterpart for the COMS entity 
associated with a device type. 

GEMCOS Enttty COMS Entity 

DEVICE <ID> Device-type name or names 
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GEMCOS Sources for COMS Entities and Attributes 



Station Counterparts 



The following entity comparison shows the GEMCOS counterpart for the COMS entities 
associated with stations. 



GEMCOS Entity 

STATION <ID> 
SYSTEM <ID> 
DEVICE <ID> orSTALIST 



STATION MKEPOSITION 

STATION SYSTEMSPOSTATION GLOBAL 
SYSTEMSPO 



STATION CONTINUOUSLOGON 



COMS Entity 

Station name 
Default window 
Device type 
Default usercode 
Valid security-category list 
Trancode position 
Control station 

Super user 
System user 
Privileged user 
Continuous log on 



Window Counterparts 

The following entity comparison shows the GEMCOS counterpart for the COMS entities 
associated with windows. 



GEMCOS Entity 
SYSTEM <ID> 



17 



COMS Entity 

Window name 

Maximum users 

Maximum dialogs 

Maximum trancode size 

Remote-file window 

Remote-file program 

Message control system (MCS) window 

MCS title 

Notify Open 

Notification text 

Notify On 

Notification text 



8600 1567-000 



B-3 



B-A 8600 1567-000 



Glossary 



A 

agenda 

In the Communications Management System (COMS), an entity used for message 
routing that consists of a processing-item list and a destination. An agenda can be 
applied to messi^ies that are received or sent by application programs. 

Agenda Processor library 

In the Communications Management System (COMS), an internal library that applies 
processing items to messages by executing the processing-item lists that E^endas specify. 

ALGOL 

Algorithmic lai^uage. A structtired, h^h-level programming lai^^uage that provides 
the basis for the stack architecture of the Unisys A Series sjrstems. ALGOL was the 
first block-structured language developed in the 1960s and served as a basis for such 
languages as Pascal and Ada. It is still used extensively on A Series systems, primarily 
for systems programming. 

attribute 

The information that describes a characteristic of an entity. 



B 

BNA 

The network architecture used on A Series, B 1000, and V Series systems as well as 
CP 9500 and CP 2000 conmiimications processors to connect multiple, independent, 
compatible computer systems into a network for distributed processing and resource 
sharix^. 



c 

CANDE 

See Command and Edit. 
COBOL(68) 

A version of the COBOL language that is compatible with the American National 
Standard X3.23-1968. 

COBOL74 

A version of the COBOL language that is compatible with the American National 
Standard X3.23-1974. 
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Command and Edit (CANDE) 

A time<sharing message control system (MCS) that enables a user to create and edit 
files, and to develop, test, and execute programs interactively. 

Communications Management System (COMS) 

A general message control system (MCS) that controls online environments on A Series 
systems. COMS can support the processing of multiprogram transactions, single-station 
remote files, and multistation remote files. See also COMS (Full-Featured) and COMS 
(KemeD. 



COMS 



See Communications Managem^t SystCToi. 



COMS (Full-Featured) 

A v^^on of the Communications Management System (COMS) message control system 
(MCS) that provides full configuration capabilities through the COMS Utility. The 
COMS Utility enables the user to define and customize a COMS transaction processing 
CTtvironment, which provides additional features like transaction-based routing and 
database recovery. In addition, the user can track COly^ statistics and use GEMCOS 
migration aids. 

COMS (Kernel) 

The transitional, temporary version of the Communications Management System 
(COMS) message control system (MCS). COMS creates a predefined configuration file 
that enables the user to use the window feature with the following three windows: a 
Menu-Assisted Resource Control (MARQ window with dg^t dialogs, a C!ommand and 
Edit (CANDE) window with two dialogs, and a Greneralized Message Control System 
(GEMCOS) window with one diedog. Additional^, the user can communicate with 
remote-file programs. 

COMSUtiUty 

The Communications Management System (COMS) program that defines and maintains 
the specifications stored in the COMS configuration file. 

conversion area 

In the (Communications Management System (COMS), the user data space in the header 
of a message. The conversation area is user defined and can contain information passed 
by a program or processing item. When used with a direct-window interface, this area 
contains the telephone number to be dialed. 

CP 2000 

See C!P 2000 communications processor. 

CP 2000 communications processor 

A data communications processor (DC?) that provides communications interfaces to local 
area networks (LANs) and wide area networks (WANs), including BNA Version 2 and 
Transmisaon Ck>ntrol Protocol/Internet Protocol (TCP/IP) networks. The CP 2000 also 
provides connections to terminals controlled 1^ BNA Version 2 software. 
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D 

Data Communications ALGOL (DCALGOL) 

A Uni^ language based on ALGOL that contains extensions for writing message 
control S3rstem (MCS) programs and other spedaHzed system programs. 

data communications controller (DCC) 

The subset of the master control program (MOP) operating as a group of independent 
tasks, each associated with one network support processor (NSP) or data 
conmiimications data link processor (DCDLP). 

data communications data link processor (DCDLP) 

A data commmiications processor (DCP) that combines the functions of a network 
support processor (NSP) and a line support processor (LSP) into one physical data link 
processor (DLP) and supports up to four lines of communication. 

Data Management System n (DMSII) 

A specialized system software package used to describe a database and maiatain the 
relationships among the data elements in the database. 

DCALGOL 

See Data C!ommimications ALGOL. 

DCC 

See data communications controller. 

DCDLP 

See data communications data link processor, 
direct window 

In the Ommunications Mans^ment System (COMS), a type of window that enables 
the user to route messages directly to COMS, while using all the COMS capabilities for 
preprocessing and postprocessing of messages. 

DLS number 

A construct made up of three numbers, each separated by a colon (:). The first nimiber 
is the relative network support processor (NSP) ntmiber, which was previously the data 
communications processor (DCP) number. The second number is the line number. The 
third number is the relative station number within the line. 

DMSn 

See Data Management System n. 

E 

end of file (EOF) 

A code at the end of a data file that signals that the last record in the file has been 
processed. 
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end of job (EOJ) 

(1) The termination of processing of a job. (2) In the Communications Management 
System (COMS) and X.25, the control code that signals the receiver that a job has 
completed. 

end of task (EOT) 

The termination of processing of a task. 

end of transmission (EOT) 

A control code that tells the receiver that all user data (text) has been sent. 



entity 

(1) An item about which information is stored. An entity can be tangible or intangible 
and is further defined by attributes, which are the characteristics of the entity. (2) In 
the O)nmiimications Management System (COMS), a category of items within the 
configuration file. (3) In the GreneraHzed Message Control System (GEMCOS), a 
category of information within the GEMCOS control file. (4) Any object defined in the 
Advanced Data Dictionary System (ADDS). To ADDS, an entity can be a Screen Design 
EEuality (SDF) field, form, or formIibrai3r, an attribute or class in a Semantic Information 
Manager (SIM) database; a data set, group, or item in a Data Management System n 
(DMSn) database; or the entire SIM or DMSII database. Note that the definitions that 
are stored in ADDS--objects and their relationships-are themselves known as entities. 
(5) In the Screen Design Facility (SDF), a field, form, or formlibrary about which 
information is stored. (6) In the InfoExec™ environment, the basic imit of a Semantic 
Information Manager (SIM) database. A SIM entity can be any member of a SIM class, 
such as an employee, a department, or a project 



entry point 

A procedure or fimction that is a library object. 



EOF 

See end of file. 

EOJ 

See end of job. 

EOT 

See end of task, end of transmission. 

F 

format support library (FS-UB) 

A library provided by the Communications Management System (COMS) that is used 
to maintffln Groiieralized Message Conti'ol System (GEMCOS) input formatting, output 
formatting, forms requests, paging, and library formats. 



InfoExec is a trademark of Unisys Corporation. 
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formatting 

The handling of fields within a mess£^e prior to their delivery to a program (input 
message) or a terminal (output message). 

FS-LIB 

See format support libraiy. 



G 

GEMCOS 

See Generalized Message Control System. 

Generalized Message Control System (GEMCOS) 

A message control system (MCS) developed for online systems. GEMCOS is transaction 
oriented. 



I/O 

Input/output. An operation in which the system reads data from or writes data to a file 
on a peripheral device such as a disk drive. 



input format 

A format for messages to be delivered to a program. 



L 

library 

(1) A collection of one or more named routines or library objects that are stored in a file 
and can be accessed by other programs. (2) A program that exports otrjects for use by 
user programs. (3) CVDP) A collection of related files. 

logical station number (LSN) 

A unique number assigned to each station in a network and each pseudostation allocated 
by a message CGntrd system (MCS). Each station has an LSN asagned according to the 
order in which the stations are defined. 

LSN 

See logical station number. 

M 

MARC 

See Menu-Assisted Resource Control 

MCS 

See message control system. 
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Menu-Assisted Resource Control (MARC) 

A menu-driven interface to A Series systems that also enables direct entxy of commands. 

message control s^rstem (MCS) 

(1) A program that controls the flow of messages between terminals, application 
programs, and the operating system. MCS functions can include message routing, access 
control, audit and recovery, system management, and message formatting. (2) In X.25, a 
program that acts as an interface betwe^ the application and the Network Definition 
Language II (NDLH) and handles such functions as routing; security, auditmg, and 
changes in the network. 

MLS 

See Multilingual System. 

Multilingual System (MLS) 

An environment that can process information using the standards and functional 
requirements of different localities, cultures, or lines of business. The processing of 
information depends on the ccsversion, languages, and conventions that are defined for 
the system. For example, output messages, online help text, menus, and screens can 
be developed and accessed in different natural languages, such as English, French, or 
Japanese. 



N 

NAE 

5ee negative acknowledgement 

NDLn 

See Network Definition Language n. 

negative acknowledgment (NAK) 

A response that occurs if a terminal is not able to respond to a poll/select inquiry. 

Network Definition Language II (NDLH) 

The Unisys language used to describe the physical, logical, and functional characteristics 
of the data communications subsystem to network support processors (NSPs), line 
support processors (LSFs), and data communications data link processors (DC^DLPs). 

network support processor (NSP) 

A data communications suh^jrstCTi processor that controls the interface between a host 
system and the data communications peripherals. The NSP executes the code generated 
by the Network Definition Language II (NDUD compiler for line control and editor 
procedures. An NSP can also control line support processors (LSPs). 

NSP 

See network support processor. 
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0 

ODT 

See operator display terminal, 
operating system 

The set of programs that control the operational environment of a computer system 
by activities such as managing processors, memoxy, and peripherals; logging system 
activities; enforcing securit3r, and executing system commands. On A Series systems, 
the operating system consists of a master control program (MCP) and system libraries 
such as CENTRALSUPPORX GENERALSUPPORX JOBFORMATTER, and 
PRINTSUPPORT. 

operator display terminal (ODT) 

A terminal or other device that is connected to the system in such a way that it can 
communicate directly with the operating system. The ODT allows operations personnel 
to accomplish system operations functions throi^ either bf two operating modes: 
system command mode or data comm mode. 

output format 

A format for messages to be delivered to a terminal. 



P 

paged format 

A format for a message that cannot be displayed on a terminal in one screen, or for a 
message that is specifically divided into sevei^ screens. 

postprocessing 

The processing done to a message by processing items after an application program 
sends out the message. 

preprocessing 

The processing that the Agenda Processor performs on a message before an application 
program receives the message. 

processing-item library 

In the Communications Management System (COMS), a user-written ALGOL library 
containii^ a set of procedures called processix^ items. A processing-item library can 
be called <miy fay the COMS Agenda Processor library to preprocess and postprocess 
messages as th^ are received and sent by programs. 



R 

relative station number (RSN) 

An integer value identifying one station of a multistation remote file. The value is 
contained in the LASTSUBFILE attribute for the file. This value is used to determine 
the station read fi*om or written to when using the READ or RECV operation, or the 
SEND or EXCPT operation, respectively. 
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remote file 

A file with the KIND attribute specified as EBMOTB. A remote file enables object 
programs to communicate interactively with a terminal 

Remote Print System (ReprintS) 

A Unisys software system that controls the routing and printing of backup files at 
remote (data comm) destinations and on SNA networks. 

Reprints 

See Remote Print System. 

restart data set (RDS) 

In Data Management System n (DMSII), a data set containing restart records that 
application programs can access to recover database information after a system failure. 

RSN 

iSee relative station number. 

S 

Screen Design Facility (SDF) 

The InterPro product used for creating forms for online, transaction-based application 
syst^ns. 

SDF 

5ee Screen Design EBualiiy. 

synchronized recovery 

(1) In the Commimications Management System (COMS), a function that resubmits 
incomplete transactions to the database aft^ a transaction-state abort, system crash, 
or rollback occurs. This COMS ftmction is called synchronized recovery because it 
reprocesses transactions in the same order that th^ were originally processed by 
multiple programs running asynchronous!}^ even if the transactions were conflicting. 

(2) In the Generalized Messs^ Control System (GEMCOS), recovery of transactions 
running concurrently prior to a system or program failure in the original database update 
sequence. This recovery is invisible to apptication programs and tenninal operators. 

T 

TCL 

See transaction control language. 

trancode 

See transaction code. 

transaction code (trancode) 

(1) A sequence of characters included in a messa^ that indicates the agenda to apply 
to a message during preprocessing or postprocessing. (2) In the Commimications 
Management System (COMS), a code that can appear in a transaction-initiating message 
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header, indicating the processing that is to be carried out. This code is used to route the 
message to the appropriate host program. 

transaction control language (TCL) 

A language that is used to describe stations, programs, and message control system 
(MCS) capabilities. 

transaction state 

In Data Management System n (DMSII), the period in a user-language program 
between a begin transaction operation and an end transaction operation. 



W 

window 

(1) In the Commimications Management System (COMS) architecture, the concept 
that enables a ntmiber of program environments to be operated independently and 
simultaneously at one station. One of the program environments can be viewed while 
the others continue to operate. (2) In the Editor, a conceptual aperture through which 
any screen-sized group of lines in a work file can be viewed. The window is said to move 
forward in the file if lines of higher sequence numbers are being displayed, and backward 
iflinesoflower sequ^ce numbers are beicqE^ displayed. (3) In the Forms Manager, a 
rectangular area in a form. (4) In data communications, a flow control mechanism, the 
size of which is equal to the ntmiber of frames, packets, or messages that can be sent 
from a transmitter to a receiver before any reverse acknowledgment is required. At the 
data terminal equipment (DTE)/data circuit terminating equipment (DCE) interface of 
a logical channel, a window is the maximtmi number of consecutive packets that can be 
transmitted. (5) A portion of a screen that has been allocated to display the contents of a 
specified area of memoiy. 
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